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Providing A Network Communication Status Description Based 

On User Characteristics 

Technical Field 

This invention relates to providing a network 
communication status description based on user 
characteristics . 

Background 

Networks such as the Internet enable users all over 
the world to share information. For example, a Web-browser 
(e.g., Microsoft® Internet Explorer®) can retrieve web-pages 
from computers in almost any country. Such networks 
typically require network nodes (e.g,, computers) to share a 
protocol that defines how the network nodes communicate. 
For example, computers on the Internet commonly communicate 
using HTTP (HyperText Transfer Protocol) . HTTP defines 
messages that a client (e.g., a browser) can send to request 
information from a server. HTTP also defines messages that 
the server uses to send back the requested information. The 
HTTP messages typically travel through a number of 
intervening agents (e.g., proxies, routers, and firewalls) en 
route to their destinations. 

As many "web- surfers" have experienced, obtaining 
information over a network is not always trouble-free. For 
example, information a user seeks may have been moved to a 
different computer. Additionally, the computer storing the 
information may be temporarily unable to provide the 
requested information, for example, when the computer 
receives too many requests at the same time. 

A server can supply an error message for display by a 
browser or other client. For example, many Web users may 
have encountered a "4 04 - File Not Found" error message 



during a browsing session. Unfortunately, error messages can 
be very technical and, therefore, have little meaning for 
novice computer users. Additionally, while network nodes in 
different countries share a communications protocol, computer 
users still speak a wide variety of languages. Thus, an 
error message in English is of little value to someone who 
only speaks French. A server administrator can configure a 
server to provide error messages in different languages. 

Siimmary 

In general, in one aspect, a method of providing a 
network communication status description based on user 
characteristics includes receiving a status indication from a 
first networked computer in response to a user's request for 
information and determining one or more characteristics of 
the user who issued the request. The method provides a 
status description corresponding to the received status and 
the determined user characteristics. 

Embodiments may include one or more of the following 
features. The method may further include transmitting the 
status description to a second networked computer. 

The status indication may indicate the success or 
failure of the user's request. The status indication may be 
a status code such as an HTTP (HyperText Transfer Protocol) 
status code. 

User characteristics may include technical 
proficiency. The technical proficiency may be inferred, for 
example, by basing the proficiency on a user's previous 
request or requests for information. 

User characteristics may include one or more 
preferred languages. The preferred languages may be 
inferred, for example, by determining a user's address or 
access number used. 



The status description may include text and/or speech 
data. The status description may include graphics, video, 
animation, sound, and instructions. The status description 
may be selected from a database of status descriptions. 

In general, in another aspect, a method of providing 
a network communication status description based on user 
characteristics includes receiving an HTTP (HyperText 
Transfer Protocol) status code from a first networked 
computer in response to a user's HTTP request for a URL 
(Universal Resource Locator) provided by the first networked 
computer. The method also includes determining one or more 
characteristics of the user who issued the request, selecting 
a status description from a database of status descriptions 
based on the received HTTP status code and the determined 
user characteristics, and transmitting the status description 
to a second networked computer. 

In general, in another aspect, a proxy for providing 
a network communication status description based on user 
characteristics includes means for receiving a status code 
from a first networked computer in response to a user's 
request for information, means for determining one or more 
characteristics of the user who issued the request, means for 
selecting a status description from a database of status 
descriptions based on the received status code and the 
determined user characteristics, and means for transmitting 
the status description to a second networked computer. 

Advantages may include one or more of the following. 
By transmitting a status description in a user's preferred 
language (s), a user can quickly understand problems that 
occurred when the user requested information and can try to 



remedy these remedy problems. By centralizing status 
descriptions in an intervening agent instead of duplicating 
the descriptions at different servers offering information, 
the servers need not waste processing time providing tailored 
status descriptions and need not provide storage for a large 
number of status descriptions. By providing status 
descriptions based on a user's technical proficiency, the 
techniques can provide a user with information likely to be 
of value to the user. 

The details of one or more embodiments of the 
invention are set forth in the accompanying drawings and 
description below. Other features, objects, and advantages 
of the invention will be apparent from the description and 
drawings, and from the claims. 

Drawing Descriptions 

FIG. 1 is a screenshot of a display that includes a 
status description in a user's preferred language. 

FIG. 2 is a flowchart of a process for providing a 
status description in a user's preferred language. 

FIG. 3 is a screenshot of a graphical user interface 
for specifying a user's preferred language (s), 

FIG. 4 is a table of HTTP status categories. 

FIG. 5 is a table of HTTP status codes. 

FIG, 6 is a diagram illustrating storage of status 
information. 

FIG. 7 is a diagram of a proxy that provides status 
information in a user's preferred language. 

FIG. 8 is a diagram of a client that provides status 
information in a user's preferred language. 



Like reference numbers and designations in the 
various drawings indicate like elements. 

Detailed Description 

5 Referring to FIG. 1, user requests for information 

(e.g., web-pages) from a network node can fail for a variety 
of reasons. For example, a user requesting an HTML 
(HyperText Markup Language) page stored on a remote computer 
on the World Wide Web may have mistyped a URL (Universal 

10 Resource Locator) identifying the page. 

As shown in FIG. 1, a user's request for information 
has failed. A browser display 100 includes a status 
description 102 (e.g., text, graphics, video, animation, 
links, and sounds) explaining the cause of failure of the 

15 user's information request. The display 100 also includes an 
appended status description 104 based on the user's 
characteristics. As shown, the appended status description 
104 is in a user's preferred language (e.g., English, German, 
French, Spanish, or Chinese) . By providing status 

2 0 descriptions in a language more readily understood by a user, 
the user can quickly comprehend and try to remedy problems in 
retrieving requested information. For example, a user can 
identify typographical errors in an entered URL and transmit 
an information request with a corrected URL, 

25 The tailored status description 104 can be provided 

based on different user characteristics such as the preferred 
language (s) of the user and/or the user's technical 
proficiency. For example, the status description 104 may 
simply state "HTTP Protocol Error: 404" to a very 

30 sophisticated user, but state "The file you entered doesn't 
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exist. Look for typos and try re-entering the location" to 
less experienced users. Descriptions provided to less 
experienced users may also include HyperText links or 
technical support telephone numbers for providing further 
assistance. By displaying a status description based on the 
user's technical proficiency, even users with little 
experience can quickly receive assistance. 

Referring to FIG. 2, a process 106 for providing 
status descriptions based on a user's characteristics can 
include examining a server's response to an information 
request to determine 110 the status (e.g., the success or 
cause of failure) of the request. The process 106 also 
determines 112 characteristics of the user making the 
request. For example, the process 106 can determine the 
preferred language (s) and technical proficiency of the user. 
Based on the determined status and user characteristics, the 
process 106 can provide a status description that corresponds 
the user characteristics. The status description may be in a 
variety of formats such as HTML, XML (Extensible Markup 
Language) , JPEG (Joint Picture Experts Group) , MPEG (Moving 
Pictures Experts Group), etc. The provided status 
description can replace or be provided in addition to (e.g., 
appended or prepended) any status descriptions provided by 
the server that processed the information request. 

The process 106 can determine 112 the preferred 
language of a user in a variety of ways. For example, HTTP 
provides a "response -language" field in HTTP information 
requests. The response- language field can include an ordered 
list of ANSI-coded indications of the user's native language. 
For example, an ANSI -coded list of "1, 0, 2" corresponds to a 



preference list of "French", "English", and "Danish". The 
user can define the contents of the response -language field 
by interacting with a browser user- interface . For example, a 
user can tailor Microsoft® Internet Explorer® by navigating 
5 through "Edit", "Internet Options", "General", "Languages" 
and entering different preferred languages. These entries 
are transmitted in each HTTP request. Referring to FIG. 3, 
America Online® provides users with the ability to declare a 
preferred language and stores the user's response in a 
P 10 database. 

l;i Alternatively, a user's preferred language can be 

Ifl inferred by identifying the access number dialed by a user to 

connect to a network or by accessing a user's billing or 
accounting information. Pending application "Data 
- 15 Localization", filed Dec. 22, 1998 (PCT/US/27217) describes 
r-r methods of inferring characteristics of a user and is 

M: incorporated herein. 

A user's technical proficiency can also be determined 
f;", in a variety of ways. For example, a user can self report 

20 their abilities. Alternatively, technical proficiency can be 
inferred, for example, by tracking a user's success rate in 
obtaining information over a network {e.g., how many errors 
does a user accumulate when trying to access web-pages) . 

Referring to FIGS. 4 and 5, HTTP and other network 
25 communication protocols define status codes that describe the 
success or failure of network communications. These codes 
describe errors, application-specific messages, whether a 
request has been redirected, etc. These codes are 
transmitted in response to problems encountered in retrieving 
3 0 and transmitting requested information. For example, an HTTP 
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response message includes a "status-code" field that includes 
a numeric representation of the status. By examining the 
status-code of a response message, the process of FIG. 2 can 
determine which status description to provide. For example, 
5 if an HTTP response message is received having a 

"status-code" field equal to "401", the process can provide a 
status description that explains that the request was not 
"authenticated." Less experienced users may not know what 
"authenticated" means and the process can provide a less 

10 technical description. 

Referring to FIG. 6, a status description database 
122 includes status information for each status code 121 in a 
variety of different languages 123. The database 122 also 
stores multiple descriptions for the same language and status 

15 code that differ in the level of technical information 

provided 125. The database 122 enables a system to quickly 
retrieve a status description tailored to a user. As shown, 
database 122 records are keyed by status code 121, ANSI 
language value 123, and technical proficiency 125 (e.g., 

20 "novice", "experienced", and "expert"). A wide variety of 
other data storage techniques could similarly provide quick 
and easy access to a description. 

In addition to or in lieu of a database, an 
intervening agent or client can use language translation 

25 software that translates text from one language to another. 
For example, SysTrans® can automatically translate text from 
English to Spanish. Using a database of pre-written 
information, however, can speed processing and avoid garbled 
sentences sometimes produced by translation software, 

30 Additionally, the use of translation software would not be 
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helpful in the cases where a server only responded with a 
status code and did not provide a status description. 

Referring to FIG. 7, including instructions that 
provide a status description based on user characteristics 
5 102 in a proxy 124 or other intervening agent enables the 

agent to provide tailored status descriptions for information 
requests that travel through the agent 124. This alleviates 
the need for each server offering information to store a 
large number of different status descriptions (e.g., [number 

10 of statuses] x [number of languages supported] x [number of 
different levels of technical explanation] x [average size of 
description] ) . Additionally, centralization of the 
processing instructions can eliminate the need for installing 
status descriptions in each client. 

15 As shown in FIG. 7, when a client 122 issues an 

information request, the proxy 124 (e.g., an Internet Service 
Provider such as America Online®) forwards the request to a 
networ)c server providing the requested information 126. When 
the proxy 124 receives the response from the network server, 

2 0 the proxy 124 can determine the status of the information 

request. If the response indicates successful operation, the 
proxy 124 can forward the received response to the client 
unaltered. Otherwise, the proxy 124 can determine one or 
more languages understood by a user, the user's technical 
25 proficiency, and other user characteristics to select a 
pre -written status description from a database 122 and 
transmit the selected description to the client. 

Referring to FIG. 8, the instructions for providing a 
status description based on user characteristics 102 also can 

3 0 reside in a client 122 instead of in an intervening agent. 
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When the client 122 receives an information request response, 
the client 122 can determine the status of the information 
request. The client 122 then can provide a status 
description tailored to the user (e.g., in language (s) 
preferred by the user) • The selected description then can be 
displayed by a browser or other application providing network 
services . 

The methods and techniques described here may be 
implemented in digital electronic circuitry, or in computer 
hardware, firmware, software, or in combinations of them. 
Apparatus embodying these techniques may include appropriate 
input and output devices, a computer processor, and a 
computer program product tangibly embodied in a 
machine-readable storage device for execution by a 
programmable processor. A process embodying these techniques 
may be performed by a programmable processor executing a 
program of instructions to perform desired functions by 
operating on input data and generating appropriate output. 
The techniques may advantageously be implemented in one or 
more computer programs that are executable on a programmable 
system including at least one programmable processor coupled 
to receive data and instructions from, and to transmit data 
and instructions to, a data storage system, at least one 
input device, and at least one output device. Each computer 
program may be implemented in a high-level procedural or 
object-oriented programming language, or in assembly or 
machine language if desired; and in any case, the language 
may be a compiled or interpreted language. Suitable 
processors include, by way of example, both general and 
special purpose microprocessors. Generally, a processor will 



receive instructions and data from a read-only memory and/or 
a random access memory. Storage devices suitable for 
tangibly embodying computer program instructions and data 
include all forms of non-volatile memory, including by way of 
5 example semiconductor memory devices, such as EPROM, EEPROM, 
and flash memory devices/ magnetic disks such as internal 
hard disks and removable disks; magneto-optical disks; and 
CD-ROM disks. Any of the foregoing may be supplemented by, 
or incorporated in, specially-designed ASICs 

10 (application-specific integrated circuits) . 

A number of embodiments of the present invention have 
been described. Nevertheless, it will be understood that 
various modifications may be made without departing from the 
spirit and scope of the invention. For example, the 

15 functions and components shown in FIGS. 7 and 8 can be 

distributed across multiple computers. Accordingly, other 
embodiments are within the scope of the following claims. 
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